In general, Cross-site Scripting, (also known as XSS), is a type of web application security vulnerability that allows an attacker to add malicious code to an application that can then execute in a user's browser or on a user's device. In XSS attacks, the victim is typically the user (i.e., a person visiting an affected webpage or executing an affected application), rather than the application or the website itself. Typically, XSS attacks target client-side rendering and scripting languages such as HTML and JavaScript to embed a malicious script in a webpage or an application. These attacks can execute any time the webpage is loaded into a user's browser, an affected application is executed on the user device, or when the user interacts with the webpage and/or application. Common outcomes of XSS attacks include browser session hijacking, stealing account credentials, displaying unwanted advertisements, and infecting the user device with a virus or other malware. The most malevolent XSS attacks can also access unrelated resources on the user device, web applications, and other networked resources, otherwise protected by the user's firewall. This is feasible because the user unknowingly permitted execution of the affected code within a trusted location (e.g., on the user device) behind the firewall.
A cross-site scripting vulnerability generally arises because many applications are designed to accept data from users and to dynamically include the received data in the application without first properly validating the received data. Three different types of cross-site scripting attacks, reflective, persistent, and DOM-based, are common. In a reflective attack, while interacting with an application (usually a web application), the user sends a request to a server, such as submitting an HTTP form. The application then responds with a page containing an echo of what the user submitted, for confirmation. Applications/web apps with XSS vulnerabilities allow potentially harmful instructions and/or data to be inserted during such transactions. For example, a malicious string of JavaScript can replace or append itself to the user supplied data. As the application executes and/or the webpage is displayed, echoing the user supplied data, the malicious code may execute on the user device.
In a persistent attack, an application, such as that provided by a web server, often stores user-supplied data without properly securing such data. In a subsequent access to a webpage served by the web server or while executing an application that accesses any stored data, the previously stored data, which can include harmful instructions, are sent to a user device via a browser and/or the application accessing the data. This kind of XSS attack is generally more dangerous because the user-supplied data is not properly sanitized before the application and/or webpage using such data are accessed by later uses. The malicious code stored by the attacker executes when a later user executes or interacts with the application and/or webpage and, as such, any later user of the application/webpage can potentially become a victim.
In one example, a JavaScript code fragment is input as part of the attacker's user name to be displayed on a user profile page. Here, a fraudulent user exploits the fact that the application receiving the input stores each user name in a local database and fails to sanitize the name field, i.e., fails to check for any vulnerabilities therein. When other users view the attacker's profile page, the code stored masquerading as the user name may be executed on the other users' devices without consent or even knowledge of the other users. Such code can be malicious, e.g., it can damage the users' devices and/or access the users' protected information without authorization.
In DOM-based XSS attacks, the attacker can exploit the Document Object Model (DOM) standard that enables application program interface (API) access to the contents of documents such as HTML and XML documents. Some applications deliver webpages and other applications that contain user-side scripts that dynamically generate application and/or webpage content without accessing a web server or another computer. According to a certain user input, these applications/webpages can modify the application/webpage content, including instructions and data, without any interaction with another computer. In a DOM-based XSS attack, the attacker can inject malicious script into an application or a webpage without any data being submitted to the server, exploiting security vulnerabilities in a client-side script and/or application.
In order to prevent or at least mitigate XSS attacks, it is beneficial to analyze and/or test webpages, server-side code and executables, and client-side code such as scripts. To this end, various known analysis and testing techniques generally apply a number of preconfigured payloads (e.g., pieces of executable code) to the object under test, i.e., a webpage, server-side code/executable, or client-side code. An XSS vulnerability in the target is detected if the payload succeeds, i.e., the payload is executed during testing. Typically, however, a large number of payloads that are applied do not succeed and, as such, the testing consumes a long time—usually several hours, if there are a large number of input vectors (i.e., parameters dependent on user input). In addition, a payload that can succeed may not be preconfigured. As such, even after spending a significant time and effort in testing, a particular XSS vulnerability may remain undetected.